Skip to content

fix(coordination): revalidate canonical claims after CAS contention - #5371

Merged
huangruiteng merged 3 commits into
mainfrom
codex/claim-contention-retry-1001
Oct 2, 2026
Merged

huangruiteng merged 3 commits into
mainfrom
codex/claim-contention-retry-1001

Conversation

@cocolord

@cocolord cocolord commented Sep 30, 2026 •

Copy link
Copy Markdown
Collaborator

Goal And Delivered Outcome

Two canonical claim commands for independent Todos can read the same provider head. Previously one succeeded and the other returned a revision conflict even though its target and write scopes were still eligible.

The TS claim owner now absorbs up to two conclusive provider-revision CAS conflicts. Every attempt uses the original operation/lease identity, rereads the receipt and complete authority, and revalidates source registration, ownership, acceptance and lease scopes. Same-Todo or overlapping-scope losers receive the current semantic rejection. Explicit revisions/transfer grants remain pinned; ambiguous writes keep the existing receipt-recovery path.

This is a bounded canonical-writer adoption under the existing TypeScript migration/shared-authority contracts. Base: main; independent of #5370.

Scope And Continuation

Complete within this scope: automatic revalidation of unrelated CAS contention in canonical claims, with public CLI adoption and no new API or provider. The generic receipt helper remains recovery-only. Recommendations are still advisory, and local writer serialization remains unchanged. Sustained multi-host contention frequency and throughput are not established by these synthetic races.

Future-facing pass: the existing claim transaction is retained as a private attempt function rather than duplicating authorization or lease rules. Retry ownership stays in the typed claim command. A broader claim-next/reservation protocol is outside this fix.

Validation

Tested exact head: 7ddeddb481924621265a424bb7f0fa02ad525f2f, integrated with immutable main 850268bffc6f7123e88f578d3743f8f6da5c5c73. The integration resolves only the two bilingual RFC conflicts and preserves both the claim-contention and scoped gate-action checkpoints.

Check Result Evidence / limitation
Complete File authority conformance passed 326 passed, zero skipped.
Complete SQLite authority conformance passed 338 passed, zero skipped.
Complete PostgreSQL authority conformance passed 322 passed, zero skipped, isolated real PostgreSQL 16.15 with disposable synthetic tenants; server stopped afterward.
Production source CLI claim/proof/transfer tests passed Seven passed.
Same-fixture real File command base/head comparison passed Seven contention cases: immutable base has five expected regression failures and two passes; exact head passes all seven. Independent ownership survives rebase; same-Todo, overlap, acceptance, source, explicit revision and bounded exhaustion checks retain authority and receipt invariants.
TS typecheck, semantic vocabulary, maintainability, diff and public-boundary checks passed No new shared vocabulary, parallel decision owner or private artifact.
Exact-scope change-quality valid Receipt cqr_beabc7329dba57135c17 matches the five-file final diff.
Risk-selected premerge failed, unchanged baseline 18 selected checks executed: nine passed and nine failed. The same nine commands fail on immutable main with the same existing default-runtime routing collision, including the nested catalog facade failure. Claim/provider/receipt paths are outside that cause and have independent passing coverage. The premerge gate remains failed; no limit, check or runtime state was changed to hide it.

No GitHub CI was consulted under the configured review policy. NoKV integration and sustained multi-host throughput were not run; this PR changes no provider implementation. Maintainer merge and resolution of the separate premerge environment hold remain required. No active Goal state was used for validation.

Frontend / Visual Evidence

UI impact: none. The existing canonical CLI claim path inherits this behavior; no frontend/Lark action contract changes.

Shared-authority RFC fixture impact

Existing native Todo/lease fixture schema is retained. Changed dimensions: claim retry admission, operation identity, write-scope exclusion and latest authority after CAS. The native/legacy provider suites preserve compatibility and receipt behavior. File, SQLite and PostgreSQL conformance arms were executed; promotion/three-arm rehearsal is not applicable because routing, promotion and projection schemas are unchanged.

Boundary Checklist

  • Public-safe product code, bilingual docs and synthetic conformance tests only.
  • No private state, raw logs, credentials, connection strings or local machine paths.
  • Every commit includes DCO sign-off; runtime change is left for maintainer merge.

cocolord and others added 2 commits October 1, 2026 03:43
Signed-off-by: lusendong.6789 <lusendong.6789@bytedance.com>
Co-authored-by: TRAE CLI <traecli@bytedance.com>
Signed-off-by: lusendong.6789 <lusendong.6789@bytedance.com>
Co-authored-by: TRAE CLI <traecli@bytedance.com>
@cocolord

Copy link
Copy Markdown
Collaborator Author

Self-review of head a38d31c62a74fbc031a4e2957397f8eaddfd3102: no blocking issue found within the submitted scope; maintainer review and merge are still required.

  • Changed surface/owner: the typed canonical claim command retries only conflict_kind=provider_revision_mismatch, at most twice. Each attempt retains the original intent and runs the full existing receipt/source/ownership/acceptance/lease checks. Generic receipt recovery and provider storage protocols are unchanged.
  • Typed-state/domain-neutrality lenses: reuses existing conflict and rejection contracts; no text-based classification or new obligation vocabulary. Explicit revisions and transfer grants remain pinned. Ambiguous effects do not become fresh writes.
  • Behavior disclosure: independent targets can absorb an unrelated head change; same-Todo and write-scope losers now receive the current semantic rejection. Recommendations remain advisory and local writer serialization is unchanged.
  • Coverage: complete File/SQLite authority suites (646 passed), isolated real PostgreSQL 16.15 suite (314 passed), final seven contention cases on all three providers (21 passed), and seven real CLI claim/transfer tests passed. Existing ambiguous-response/receipt tests retain their one-commit invariant. TS typecheck, semantic advisory, maintainability and boundary checks passed.
  • Failures/skips: the initial full run exposed eight old bare-CAS expectations; renamed semantic-rejection assertions now pass with ownership/receipt invariants retained. No unresolved executed-test failure or backend skip. NoKV and sustained multi-host throughput were not run. Manual hold: maintainer review/merge; these races do not establish field contention frequency.
  • Future-facing pass: extracted a private complete attempt under the existing command owner, avoiding a second planner or a retry policy in the generic receipt helper.

huangruiteng
huangruiteng previously approved these changes Oct 1, 2026

@huangruiteng huangruiteng left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Exact-head review: #5371

Reviewed head: a38d31c62a74fbc031a4e2957397f8eaddfd3102; immutable base: 04bf6b6c1c1d37d3b19194c91efe5b4c4d9daa7d.

没有发现阻塞问题。这次批准针对 canonical claim 的有界 CAS 恢复,不代表多主机持续吞吐、provider promotion 或合并授权。

动机

两个 Agent 认领不同 Todo 时,底层共享 revision 仍可能竞争。旧路径把这类内部 CAS 拒绝直接交给调用方,导致独立工作需要再次介入;更危险的修法则是重放旧 projection,覆盖先成功的认领。现有 shared-authority RFC 的 contention 契约要求:独立目标可以基于最新权威完成,同目标或写范围冲突仍必须拒绝。这是可独立交付的 correctness 增量,不是靠测试数量宣称全局迁移完成。

改动思路

重试放在既有 TypeScript claim owner,而非 CLI/Python/provider 各自实现。只有明确的 conflict + provider_revision_mismatch 会重新执行完整 attempt;最多增加两次尝试。每次先查同 operation 的回执,再读完整 canonical head,重做 actor/claim、Todo lifecycle、acceptance、lease 和 scope 判断。显式 revision 与 transfer grant 保持固定观察,不自动升级授权;写入结果不明确则继续由既有 receipt recovery 处理,不能当作 CAS 拒绝重试。

普通 CLI 已调用该 owner,continuation 的 revision/grant 绑定路径也保留原有边界。没有新增配置、状态表、schema、账号权限、前端/Lark 动作或调用者确认步骤。代码复用审查覆盖了 local adapter、continuation、command receipt 与 lease proof;没有增加第二个 Python 决策源。

具体改动

唯一生产改动是 todo_claim.ts 的 17 行 wrapper/私有 attempt 分离。新 claim_contention_conformance.ts 在既有真实 provider factory 上执行七类竞争;authority_store_conformance.ts 注册该组,将同 Todo 竞争和 lease 被替换后的旧 conflict 断言更新为重新校验后的具体拒绝,并保留 lost-response 的 recovered/回执检查。两份 TS migration RFC 同步披露默认行为变化及“不证明持续吞吐”的边界。五个文件全部纳入审查,没有只复核新增 happy path。

关键代码讲解

  • executeCoordinationTodoClaim:输入还是相同 claim intent、operation 和 lease key。attempt >= 2、显式 revision、transfer grant、非 conflict 或非 revision mismatch 都立即返回;不会把 lease 冲突、无权限或 ambiguous write 包装成可重试错误。
  • executeClaimAttempt:原有校验和事务主体不变。新 attempt 从回执和完整权威开始,不复用上次 prepared projection;receipt、source witness、eligibility、acceptance、lease 排他仍由原 owner 决策。成功/replay 的当前 lease proof 也仍由原 proof owner 生成。
  • claimLocalCoordinationTodo:实际 CLI 的 TS adapter,在 canonical writer 边界调用共同 claim owner,并返回真实 provider/readback 来源;没有新增 legacy fallback。它未被修改,但证明 wrapper 是可达生产路径,而非孤立 helper。
  • registerClaimContentionConformance:独立目标应有两个 durable winner;同目标/重叠 scope 只有一个 winner,失败方不能留下成功回执。另检查新 acceptance、固定 revision、source change 和三次耗尽;这些是状态不变量,不只是返回字段快照。

正向与失败路径

我另外用同一独立探针对 immutable base/head 做十个完整观察:通过公共 local claim entrypoint 接真实 File store,在首次 commit 前让另一真实 writer 产生 CAS 竞争;只有 pinned case 直接调用公开 typed owner,因为 local adapter 不暴露该字段。独立 Todo 在 base 返回 conflict,head 重新读取后 applied;两位 owner、两个 lease、100 个无关完整 Todo 和 projection 附加数据都保留。成功后同 operation replay 不新增效果、不改原回执或最终状态。

同 Todo、重叠 scope、竞争后已完成/已归档目标,head 分别返回 claim_owner_mismatch、write_scope_conflict、todo_not_open、todo_archived,失败方回执缺失。持续竞争恰好尝试三次后返回 conflict;显式 revision 仍只尝试一次。普通成功、dry-run、错误 actor、pinned revision 四个对照的完整观察一致。仅归一化 File 随机 store identity 派生的 revision 摘要,保留版本并检查同观察内引用绑定;没有删掉状态、错误、lease、receipt 或 effect 差异。

验证不是由替换实现生成 expected:两个独立目标不能丢失彼此、冲突方不能获得 authority、固定观察不能悄悄更新等 oracle 来自既有共享权威契约。让同一 head oracle 跑 base 会在 independent case 失败,说明不是“新旧都能绿”的空探针。初版探针的非协议 fixture 字段、dry-run 预期和 archive literal 有错误,已按既有 schema 修正;这些构造失败未算作 PR 失败或通过证据。

对主干的风险

主要风险是把 ambiguous commit 当成确定失败后重写,或重试时遗漏新的 ownership/acceptance/scope 限制。wrapper 的精确 typed status 判断、完整 attempt 重执行及既有 receipt recovery 将两者隔开。重试无 backoff,但上限仅三次,不能无限消耗或扩大 fixed grant;高争用仍返回明确 conflict,由调用者重新观察。100 个无关记录及后续 replay/readback 检查覆盖了 accumulated-state 与重复效果风险,没有用截断 display 当权威来源。

我在该 exact head 实际执行:

  • File + SQLite 原生 authority suites:648 passed,0 failed/0 skipped。
  • 隔离真实 PostgreSQL 16.15:npm run test:postgresql-authority-store,315 passed,0 failed/0 skipped;仅合成夹具,临时实例已停止。
  • 实际 Python→TS CLI claim/transfer/proof tests:7 passed,覆盖 File/SQLite、replay、projection recovery、lease lifecycle 与 transfer。
  • npm run typecheck:control-plane、全树 semantic-vocabulary smoke、control-plane maintainability ratchet、changed-diff advisory、whitespace 与五个候选文件 public-boundary scan:通过。advisory 无支持语法中的新 vocabulary 定义,不将它视为语义等价证明。

没有查询或等待远端 CI;没有验证 live NoKV、部署晋升或跨主机持续负载。没有修改 UI/配置入口,其 adapter/request/readback 契约未变,故不需要为本修复新增 companion UI。长期任务结果是减少内部 revision 竞争造成的重复操作,同时保留恢复、拒绝和幂等边界;用户无需重新填写已知 intent 或增加批准步骤。

我的整体评价

APPROVE。这是现有 TS authority owner 的小而完整修复,生产增量与故障范围相称。未来重构检查已落实为 wrapper/单次 attempt 分离,复用旧 receipt/lease/source owner;不建议扩成通用 retry framework,也不因大型文件存在就扩大迁移。剩余多主机吞吐和 provider 准入仍由现有 shared-authority / TS migration acceptance 负责。本批准不关闭那些验收,也不授权合并。发布后应按 review capability 执行旧阻塞评审核对;只有逐条证实已解决且具备权限,才可原生撤销,不能凭本批准清除异议。

English verdict: APPROVE - a38d31c62a74fbc031a4e2957397f8eaddfd3102: bounded conclusive-CAS retries revalidate canonical authority and preserve pinned/ambiguous recovery. Verified 648 File/SQLite tests, 315 real PostgreSQL tests, 7 CLI tests and ten independent immutable base/head observations. No sustained-throughput or merge authorization claim.

@mergify

mergify Bot commented Oct 1, 2026

Copy link
Copy Markdown

This pull request has merge conflicts with main and cannot be merged
until they are resolved. Please rebase or merge the base branch, @cocolord.

Choose the remote for the base repository, not an out-of-date fork.
For a fork clone, first inspect git remote -v; upstream must point
to https://github.com/loopx-project/loopx.git. If it is absent, add it
with git remote add upstream https://github.com/loopx-project/loopx.git.
Then run:

git fetch upstream
git rebase upstream/main
# Resolve each conflict, git add the resolved files, then git rebase --continue.
git push --force-with-lease origin HEAD

For a same-repository clone whose origin points to
https://github.com/loopx-project/loopx.git, use origin instead of
upstream for fetch/rebase. If you prefer merging the base, use
git merge <base-remote>/main and push normally.

Keep the DCO Signed-off-by trailer on every commit when you rebase.
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork

@mergify mergify Bot added the needs-rebase Mergify: the pull request has merge conflicts with its base branch label Oct 1, 2026
Signed-off-by: huangruiteng <huangrt01@163.com>
@mergify mergify Bot removed the needs-rebase Mergify: the pull request has merge conflicts with its base branch label Oct 1, 2026

@huangruiteng huangruiteng left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed exact head 7ddeddb481924621265a424bb7f0fa02ad525f2f, against immutable main 850268bffc6f7123e88f578d3743f8f6da5c5c73.

未发现这份 PR 的阻塞缺陷。独立认领的争抢修复已经过真实 provider 和原有 CLI 路径验证;本地 premerge 有单独的主干/环境阻塞,不能宣称全绿或已可合并。

动机

两个独立 Todo 从同一 canonical head 发起认领,原来其中一个即使仍有合法 owner 和不重叠的写范围,也只能收到 CAS 冲突,再让调用方重跑。七个相同的真实 File 场景在 immutable main 上有五个预期回归失败、两个保留行为通过;本 head 七个全部通过。这修复 canonical writer 的有界行为,不代表完整 App 协作、持续多主机吞吐或推荐项预留已验收。

改动思路

复用既有 TS claim owner,提取完整的私有 attempt,再用至多两次重试处理明确的 provider_revision_mismatch。每次读取同一个 operation 的回执和完整权威,重验来源、owner、acceptance 和 lease/write scopes。doing nothing 保留无谓的重跑;在通用 receipt helper 或 Python caller 加重试会形成错误的权限/结果不明确边界,所以当前 17 行生产改动归属合理。

具体改动

  • executeCoordinationTodoClaim 包装原有完整 executeClaimAttempt;显式 revision、transfer grant、非 CAS 冲突、语义拒绝和结果不明确的写入保持原监督路径。local_authority_runtime.ts 与 todo_continuation.ts 继续调用同一个 command,不增加新入口或持久化字段。
  • claim_contention_conformance.ts 以真实存储 CAS 和调度 barrier 检验独立/同 Todo/写范围碰撞、新 acceptance、source、pinned revision 和耗尽。独立场景读回两个 winner 的 owner/lease,重复 operation 的原回执保持不变;失败方无认领回执。barrier 只改变时序,不伪造成功、回执或 postcondition。
  • authority_store_conformance.ts 注册七个共用场景,并将旧的 bare-conflict 断言改名为当前语义拒绝断言;原有 owner、lease、响应丢失/回执恢复不变量仍在。
  • 中英文 TS migration RFC 说明改变的默认行为和适用 caller。本次合入 main 只修复两处 RFC 文本冲突,同时保留 claim-contention 与 scoped gate-action 的检查点;原生产实现相对前一次 head 没改。

对主干的风险

最高风险是重试把已变更的 owner、acceptance 或写范围当成旧观察,或把不明确成功重新写一遍。完整 attempt、原 operation/lease key 和精确 conflict predicate 阻止这些路径;相同目标/重叠范围只保留一个 owner,新 acceptance 拒绝无回执,pinned intent 不重试,第三次冲突停止,既有丢响应恢复保持一个 commit。没有字符串启发式、平行 Python 决策 owner、新 authority 名称、feature gate 或自动加载指令。相关 conformance 和真实 CLI 测试覆盖持久化读回、replay、retirement、transfer;UI/Lark 的配置和动作契约没有变化,无需额外用户步骤。

本 head 的完整 File 326、SQLite 338、隔离真实 PostgreSQL 16.15 322 个测试全部通过、零跳过;七个源 CLI claim/proof/transfer 测试通过,TS typecheck、语义 inventory、maintainability、diff 和公共边界检查通过。PostgreSQL 使用一次性合成租户,结束后已停机。精确五文件 quality receipt cqr_beabc7329dba57135c17 有效。

风险选择的 premerge 执行了 18 项:九项通过,九项失败。对 immutable main 执行同样九条失败命令,复现相同的 default-runtime routing collision:八个相同 ValueError,以及 catalog-planner 嵌套 facade 的同一失败断言。此次 diff 不修改其 causal paths,且 claim invariant 有独立真实后端通过证据,因此这是独立的主干/环境 hold,不是这份 PR 的回归。premerge gate 仍为 failed,未删除检查、提高预算、修改活跃状态或伪装通过。按当前 wait_for_ci=false 未读取/等待 CI。NoKV integration 与持续多主机吞吐未运行,不能凭这些测试宣称已通过。

我的整体评价

APPROVE,限此 exact head 的完整 PR 判断。目标增量明确、生产机制有界、权威和失败监督继续共用原 owner,测试保护真实可复现回归而非新增抽象。未来重构检查已落实为私有完整 attempt,未添加通用 retry 框架或兼容分叉。维护者合并与独立 premerge hold 仍需单独处理;本评审没有合并授权,也未升级本机或关闭父级产品验收。

English verdict: APPROVE - 7ddeddb481924621265a424bb7f0fa02ad525f2f. Bounded canonical claim revalidation preserves receipt identity and authority; File 326, SQLite 338, real PostgreSQL 322 and seven CLI tests pass. Five expected base regressions disappear in the same seven-case File comparison. Nine premerge failures reproduce unchanged on immutable main; the separate merge hold remains. CI was not consulted.

@huangruiteng
huangruiteng merged commit a7c21ba into main Oct 2, 2026
28 of 53 checks passed
@huangruiteng
huangruiteng deleted the codex/claim-contention-retry-1001 branch October 2, 2026 04:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants